-
Notifications
You must be signed in to change notification settings - Fork 3.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Doc]Restructure monitoring docs to support new and legacy internal collectors #11714
Conversation
…xed all the `xpack.monitoring.*` references
9b62f01
to
a378ad4
Compare
a378ad4
to
99538db
Compare
f4f3b23
to
19ca70e
Compare
19ca70e
to
8884fb7
Compare
LGTM |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good so far! Couple of nitpicks and suggestions
`xpack.monitoring.collection.enabled` setting on Logstash. You must use the | ||
`xpack.monitoring.enabled` setting to enable and disable data collection. | ||
WARNING: Unlike for {es} and {kib} monitoring, there is no | ||
`pack.monitoring.collection.enabled` setting on Logstash. You must use the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Typo
See <<monitoring-settings, Monitoring Settings>> for the list of settings. | ||
|
||
If you don’t have an Elasticsearch output plugin configured in the pipelines, | ||
add the setting `monitoring.cluster_uuid` to your logstash.yml. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need to give an explanation of what this should be, and how they can retrieve it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure how much we should invest in the legacy component as it is no longer one of the preferred approaches. Let's discuss.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
True, although we could just use the description from the newer mechanism
@@ -0,0 +1,152 @@ | |||
[role="xpack"] | |||
[[monitoring-internal-collection-legacy]] | |||
=== Collect {ls} monitoring data using legacy internal collectors |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we have a description of what is meant by 'legacy'?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
--------------------------------------------------- | ||
|
||
All data produced by {monitoring} for Logstash is indexed in the monitoring | ||
All data produced by Logstash monitoring is indexed in the monitoring |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Need to verify whether this is still correct
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TBD
This is particularly important to remember when you move from development | ||
environments to production environments, where you often have dedicated | ||
monitoring clusters. | ||
IMPORTANT: When discussing security relative to the `elasticsearch` output, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this is still correct as we don't route through production clusters any more
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TBD
|
||
The universally unique identifier (UUID) for the monitoring cluster. | ||
By default, {ls} identifies and uses the `cluster uuid` from the first |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It uses cluster_uuid
s from each of the elasticsearch outputs, rather than just the first
|
||
Optional settings that provide the paths to the Java keystore (JKS) to validate | ||
the client’s certificate. | ||
|
||
`xpack.monitoring.elasticsearch.ssl.keystore.password`:: | ||
`monitoring.elasticsearch.ssl.keystore.password`:: | ||
|
||
Optional settings that provide the password to the keystore. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also need to change verification_mode
|
||
Finds all {es} cluster nodes and adds them to the hosts list. | ||
|
||
Defaults to `false`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
eb5670d
to
b11f6cb
Compare
b11f6cb
to
7a5e64e
Compare
These pieces live outside of the default Logstash pipeline in a dedicated | ||
monitoring pipeline. This configuration ensures that all data and processing has | ||
a minimal impact on ordinary Logstash processing. Existing Logstash features, | ||
such as the <<plugins-outputs-elasticsearch,`elasticsearch` output>>, can be |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know this comes from previously written copy - but I'm not sure what it is trying to say. I think it is trying to talk about the reuse of certain features from the elasticsearch output, such as retry, but I'm not 100%
@karenzone - I'm fine with committing this as is, and then work on the fine details in a subsequent PR |
This PR is getting crushed under its own weight. I will merge what we have here, and immediately open a new one to track final comments. Work continues in #11789 |
…ollectors (elastic#11714) * [Doc] added description of xpack.monitoring.collection.write_direct.enabled setting * Added page to mark as deprecated the legacy internal collector and fixed all the `xpack.monitoring.*` references * Included legacy collector file into monitoring overview * Restructure monitoring docs * Incorporate review comments Co-authored-by: andsel <selva.andre@gmail.com>
…tors (#11714) * [Doc] added description of xpack.monitoring.collection.write_direct.enabled setting * Added page to mark as deprecated the legacy internal collector and fixed all the `xpack.monitoring.*` references * Included legacy collector file into monitoring overview * Restructure monitoring docs * Incorporate review comments Co-authored-by: andsel <selva.andre@gmail.com> Fixes #11787
…tors (#11714) * [Doc] added description of xpack.monitoring.collection.write_direct.enabled setting * Added page to mark as deprecated the legacy internal collector and fixed all the `xpack.monitoring.*` references * Included legacy collector file into monitoring overview * Restructure monitoring docs * Incorporate review comments Co-authored-by: andsel <selva.andre@gmail.com> Fixes #11787
This PR starts with the goodness of #11586, pulls in doc architecture changes from #11614, and resolves recently introduced conflicts.
PREVIEW: http://logstash_11714.docs-preview.app.elstc.co/guide/en/logstash/master/configuring-logstash.html